InfoMagic Standards 1994 January/InfoMagic Standards - January 1994.iso/inet/ietf/osids/90dec.min

Text File | 1993-02-17 | 31KB | 785 lines

CURRENT_MEETING_REPORT_


Reported by Richard Colella/NIST, Steve Kille/UCL
and Peter Whittaker/BNR

OSIDS Minutes

Agenda

Introduction

The meeting was opened by the Chair, Steve Kille (UCL). Introductions
were made and minute-takers were solicited.  The proposed agenda was
approved and the meeting proceeded accordingly.

Minutes of Previous Meeting

The minutes of the San Jose meeting were approved with minor changes.

Document Distribution

A number of attendees had problems with document distribution.


  1. ASCII documents were formatted for A4 size paper, which is
     inconvenient for those in the U.S.
  2. ASCII versions of the documents were somewhat idiosyncratic in
     format -- Steve pointed out that the primary form of documents he
     generates is PostScript and he was not intending to spend
     significant amounts of time reworking the ASCII versions,
  3. A number of people could not print the PostScript versions of the
     papers retrieved from CNRI -- Steve said that this problem was
     easily correctable and he would take care of it.
  4. A few people remarked about late distribution of documents and a
     consequent lack of time to obtain and review them prior to the
     meeting.


Statement of Objectives/Scope/History

Steve spent a few minutes reviewing the objectives, scope, and history

                                   1






of the group for those who were not at San Jose.  He emphasized that the
DSWG was chartered to develop a technical framework for an X.500
deployment, but was not intent on being the instrument for deployment.

Introduction of Documents

Steve briefly introduced each of the documents that were input to the
meeting:


   o ``Replication Requirement to Provide an Internet Directory Using
     X.500.''  S.E.Kille.
   o ``Replication to Provide an Internet Directory Using X.500:  A
     Proposed Solution.''  S.E.Kille.
   o ``IETF Directory Working Group Scope (Version 3).''  S.E.Kille.
   o ``The COSINE and Internet X.500 Naming Architecture.''  P.Barker
     and S.E.Kille.
   o ``Building an Internet Directory Using X.500.''  S.E.Kille.
   o ``An Interim Approach to Use of Network Addresses.''  S.E.Kille.
   o ``A String Encoding of Presentation Addresses.''  S.E.Kille.
   o Using the OSI Directory to Achieve User Friendly Naming.''
     S.E.Kille.


Liaisons

NADF -- Marshall Rose (PSI)

The North American Directory Forum (NADF) is a consortium of service
providers and potential service providers of public X.400 and X.500
services.  The NADF has as its focus the North American market.
However, they realize the need for international connections, possibly
through multi-lateral agreements.  Their raison d'etre is to figure out
how to share proprietary information, required to provide a seamless
service, without compromising their business interests.

The NADF has had four meetings to date.  Their next meeting is in March,
1991.  Stable technical proposals addressing some of the NADF members'
concerns will probably be made in March, but the consensus process makes
actual timeliness for agreements uncertain.

The primary contact for the NADF is Don Casey (Western Union).  To
provide continuity, a standing Chair, Ted Meyer (Rapport), has been
retained.

OIW Dir SIG -- You-Bong Weon-Yoon (ATT)

                                   2






The OSI Implementors' Workshop (OIW) produces multi-vendor agreements
based on OSI standards.  The Directory Special Interest Group (Dir SIG)
produces agreements on the X.500/ISO 9594 standard.  Current work in the
SIG is in developing international standard profiles (ISPs) through
coordination with the two other regional OSI workshops, EWOS in Europe
and AOW in the Pacific rim area.

Beginning in the December, 1990 meeting, the SIG will begin developing
multi-vendor implementation agreements on replication, access control,
and distributed operations (the latter will be coordinated with the
OSINET work on interoperability test development).

RARE WG3 -- Steve Kille (UCL)

RARE WG3 has two subgroups of interest:  a user information area and a
group working on directories.  The Directory group has an analogous
function in Europe to this Working Group of the IETF. The next meeting
of RARE WG3 is January 17-18 in Brussels.

ISO/CCITT Meeting in Ottawa -- Steve Kille (UCL)

Steve summarized the current work in Directory standardization as it
stood after the Ottawa meeting.  The main areas of interest were in:


   o Extensions to the information model in the areas of schema (e.g.,
     publication) and operational attributes (i.e., those associated
     with a subtree, such as access control defaults).
   o Abstract services -- e.g., paged results (does not deal with
     collating).
   o Matching rules -- will be user-extensible, rather more formally
     defined than today, and bound to attribute syntax.
   o Replication -- now a CD (Committee Draft -- what used to be a DP);
     defines incremental shadowing, among other paradigms.
   o Distributed entries -- large and complex document, not well
     organized and difficult to comprehend.  CCITT is intent on seeing
     this in 1992, but it is not believed to even be a Work Item in IEC.
   o Short-form names -- some support is expected in 1992, though not
     necessarily a good technical solution.
   o Migration from '88 to '92 X.500 -- a document is available on this.
   o Access control -- work is progressing, but the editor recently
     resigned.  A new editor has taken over and the access control
     documents have been reissued on a second PDAM ballot (Proposed
     Draft Amendment -- used to be PDAD).


PSI White Pages Pilot Presentation -- Marshall Rose (PSI)


                                   3






Information is available as PSI TR 90-05-10-1 and PSI TR 90-09-10-1 from
[e-mail].

Marshall provided an overview of the PSI WP Pilot.  As a digression, he
described an alternative name registration scheme based on the existing
civilian naming infrastructure for states, counties, cites, etc.  Some
questions remain.  This will likely come onto the agenda at the next
meeting.

FOX -- Paul Mockapetris (DARPA)

Paul briefly discussed the Field Operational X.500 (FOX) project that
DARPA is funding.  It is based on a pair of meetings that occurred two
years ago which resulted in RFC 1107.  There are four participants:


  1. ISI -- main contractor and responsible for project oversight.
  2. NYSERNet/PSI.
  3. Merit.
  4. SRI.


The objectives are twofold:


  1. Get X.500 closer to operational status.
  2. Demonstrate interoperability among multiple X.500 implementations.


SRI will use the NIST implementation and investigate supporting some of
their traditional roles, such as registration.  Merit is considering
using X.500 to publish network numbers.  PSI will be cooperating in
interoperability testing with the NIST implementation and another
implementation (as yet undecided).

Cosine Pilot Directory Service -- Steve Kille (UCL)

The slides of this talk are available from UCL. Mail to
[e-mail].

Scope of Group and Review of Charter

Fundamentally, there were no significant disagreements about what the
scope and charter documents say.  There were two specific decisions
made:

                                   4






  1. The scope should specifically state that the aim of the group is to
     align with the base standards and profiles on the extensions when
     these become available, and,
  2. The charter will be collapsed into the scope document.


Infrastructure Strategy

The document ``Building an Internet Directory Using X.500'' was
discussed.  The substance of the discussions was:


   o The document needs a caveat that this approach will not necessarily
     address everyone's X.500 needs.
   o Need to address the issue of name allocation at the top levels of
     the naming tree.
   o Need to do a better job of naming DSAs, rather than just having
     them named high up in the tree (which is awkward).
   o Under the section on replication of knowledge and data, add that an
     intercept strategy could be defined by others (e.g., the OIW Dir
     SIG), not necessarily by this Working Group.
   o In Section 3.3, the sentence that begins, ``There is a requirement
     to extend...''  will be amended to read, ``There may be a
     requirement to extend...''.


There was general agreement on the contents of the document and folks
felt that it should move forward.  Steve proposed that the target should
be to have it become an RFC in one to six months.

Replication Requirements and Scheme

A number of issues arose during the discussion of replication:


   o Lower-layer stacks -- combinations of LL stacks should be allowed
     even thought this results in less-than full interconnectivity of
     DSAs.  However, guidance should be given on the desirability of
     having increasingly richer connectivity as one moves higher up in
     the tree.
   o Remove Section 3 of requirements document -- this is either a
     trivial or intractable problem; in either case, no statement is
     needed.
   o Section 5 of requirements -- there was some confusion about what
     this section meant.  Steve agreed to rewrite it in words similar to
     those he used in explaining it.
   o Section 6 of requirements -- the new scaling target will be 100,000
     non-leaf entries, given that this is at least an order of magnitude

                                   5






     greater than what we think is really required.
   o Replication approach -- after some discussion of the appropriate
     approach to take to replication --- a non-standard scheme such as
     that in QUIPU, an intercept strategy, or wait for the standard.
     The general discussion was inconclusive.  A subgroup, consisting of
     those most active in the overall disucssions was formed (DO, PM,
     PK, GM, SK) to look at the problems, and in particular the issues
     of migration.  The consensus of the off-line discussion was that
     the best approach, all things considered, was to use a scheme based
     on that described in the replication proposed solution document.
     This was agreed to by the rest of the Working Group.  Also agreed
     was that a replication scheme based on the standards work will be
     adopted when available.  The interim nature of the solution should
     be emphasized.  It was noted that DUA/DSA interaction is not
     affected.


Domains and X.500

There was some discussion on how to represent Domain Names (DN) (i.e.,
the attributes) in the X.500 DIT: octet strings or IA5 strings.  There
seemed to be some confusion about what the implications of this are.
Steve said that he would talk to Paul Mockapetris off-line and figure
out what the issues really are.

There was some lengthy discussion on the utility of storing DNS
information in the DIT.

Steve agreed to make the minor changes to the document suggested by the
discussion.  Otherwise, he will progress the document as an RFC pretty
much as is.

Day 2

Gita Gopal of Bellcore gave a presentation on a Bellcore research
project studying methods of providing support for distributed entries in
a heterogeneous multi-server, multi-protocol, multi-media, multi-context
environment.

The Bellcore method is based on a central Linking Data Base, (LDB) which
contains one entry per person keyed on a unique Personal Identifier
(PID). Each entry contains references to all known Databases (DB)
holding information about the particular individual, as well as the
protocol information necessary to access those DBs (i.e., J. Foobar,
Widget Inc, X.500 DSA, RFC1006 address, etc...).

The chief goal of this project is to allow users to access any and all

                                   6






information about individuals maintained by various DBs using only
information from a particular DB. For example, given a DN for a person's
business entry (i.e., an organizationalPerson), a user would be able to
send mail to that person's home by telling a UA to check the LDB and use
the business DN to find a residential OR address.

The use of aliases in an X.500 DIB was suggested as an alternative
method of achieving the same results, but was rejected as being
inapplicable to distributed entries.  The LDB solves the distributed
entry problem by considering the person as the essential element rather
then focusing on the entries themselves.

Contexts are supported using a dynamic schema.  Users are expected to
have some knowledge of the context from which they are searching (the
example of having to know what a telephone number is, and what equipment
it can be used with, before being able to make use of it, was raised as
analogous to the LDB scheme).

There are several outstanding issues that require further research:  the
LDB only links entries for people - certain simplifying assumptions have
been made based on this - the capability for handling the more complex
interactions and interlinkages that might arise when linking information
about machines, applications, or organizations; security has not been
thoroughly explored, nor have access controls; the ``publishability'' of
PIDs needs further investigation - are these to be used exclusively as
internal pointers, or has more general ``personal access (i.e., phone)
numbers''?; management and generation of unique PIDs, and the
administrative problems involved.

User Friendly Naming

Discussion then turned to Steve Kille's paper on User Friendly Naming.
The goals of this paper are the provision of:  an improved method of
transmitting names, and better handling of purported name lookup.

The result of the discussion was that Steve would revise the paper to
reflect the issues and concerns raised by the Working Group, and present
it again at the next meeting.

Among the issues raised were:


   o Tuning the algorithm to handle changes in DNs; at the moment, a
     change to a previously resolved DN makes that earlier resolution
     useless (the user would have to go through the process of resolving
     a purported name each time a DN changed).
   o The addition of ``yet another'' syntax, and the related issue of

                                   7






     other work in the field, specifically the OSF work.


It was decided that the paper would reference and track the OSF work.

Yew-Bong referred to the work of Al Grimstad of Bellcore, which was
submitted to CCITT SG VII as a corporate position on User Friendly
Naming.  Current SG work should also be tracked.

The X.500 SG is unlikely to provide a standard until 1996:  should this
method be submitted for SG VII consideration?

Moving from one machine to another:  is it reasonable to expect the same
syntax to work under different architectures (i.e., VM and Unix, where,
for example, the meaning of ```' to the command line interpreter is
vastly different (quote on Unix, escape character on VM).

The related issue of allowing a user to ``tune'' his environment:
different machines (under the control of different organizations) might
have different ``correct'' behaviour.  User customization might hide or
expose these differences, and make searching more difficult.

Vinton Cerf and Peter Mierswa suggested that User Friendly Names are
inappropriate as an ``exchange format'':  only DNs should be relied
upon, and communicated between users.  In addition, Vint suggested that
``guessability'' was less important than exactness.

Paul Mockapetris raised the question of the ``Monte Carlo'' method of
name resolution:  users guess at a name and receive a list of
possibilities; they continue guessing until they get the DN they want or
need.  The user interface should allow this behaviour.

The current model does not handle deep DITs very well; more work is
needed in this area.  It would help if the top two or three levels had
``non-obscure'' names.  Wild Card searches (especially leading Wild
Cards) need further investigation.  Multiple occurrences of the same
string in a DN (i.e., as both a county and a city) must be underlined to
the user.  DNs should always be returned when resolved - should users be
able to build dependencies on purported names?  Care must be taken when
stripping RDNs for ``displayability''.

Replication Solutions

Steve introduced this section by noting that several documents bear
directly on this subject, notably the proposed RFCs on Presentation
Address Representation and Network Address Representation.  It was

                                   8






decided that these would be dealt with first.

Network Addressing

Steve's summary of the problem, and the solution offered in his paper:

If you look at an OSI address from a DIT, you get a presentation
address, which works fine with an OSI network service, but does not work
with RFC1006 or X.25( 80) addresses, owing to the lack of an OSI network
server for these address formats.  This document provides a method,
using Telex addresses, to map non-OSI addresses onto OSI addresses.  It
is ugly, but it is functional, and requires no extensions to current
protocol.

The OSF Towers solution allows you to slice different protocols in and
out at any particular layer, allowing you a choice of transport and
network addresses.  It is a better and more elegant solution, but it
requires extension to X.500(88).  This is unacceptable, in Steve's view.
Ideally, Steve would like to push OSI/CCITT into adopting OSF Towers for
1992; we could move to it at that time.  Until then, however, it would
be better to go with an interim solution that does not require protocol
extensions, but that allows full inter-connectivity.

After a brief discussion to clarify the reasons for adopting this method
over the Towers method, it was agreed that this would be accepted as the
OSI-DS WG official recommendation on network addressing, but that it
would be explicitly noted as an interim solution only.

Among the concerns raised were:

OSF Towers and this method are both ``hacks'', the former as it requires
extensions, the latter as it uses the UCL Telex number as the basis of
network addresses.  Steve's method is less of a hack, though.

This method does not guarantee 100interpret the Telex number, then it
will not be able to contact the specified entity.  Steve admits that
this method does not give 100success, but since it uses current
protocols rather than extensions, it will offer a better success rate
than Towers.

Presentation Addresses

Steve believes this document must be taken in concurrence with the
Network Addressing document because it provides for better handling of
dotted decimal encodings, and provides an extension to presentation
address handling (`/' changed to `+') to bring our work in line with ISO

                                   9






8348 (X.213).

QUESTION: This is an extension to the standard?  RESPONSE: Steve.  Yes.

QUESTION: Is there a need to represent a presentation address that
specifies an IP address that is not an RFC1006 address?  RESPONSE:
Steve.  I hope not, but we need to be able to specify IP addresses that
are not on the Internet, such as local LANs.

After minimal discussion, it was agreed that this document should
proceed in parallel with the Network Addressing paper.

Replication Solutions

Steve provided an overview of the current proposal:

Sec.  1:  Benefits of the approach:  it has been proven in operation;
owing to its current use, there will be minimal effort involved in
moving to it as a pilot standard; the approach is simpler and easier to
implement than the current standards approach.

Sec.  2:  Enhancement of Distributed Operations to provide better
handling of referrals and chaining (an extension to the standard).  This
approach is closely tied to the previously reviewed papers on network
and presentation addresses.  It uses the concept of a ``community''
(coded into the presentation address) to allow a DSA to decide if a DUA
and another DSA can in fact communicate directly.

Sec.  3:  Extend the semantics of X.500 so that DSAs can deal more
intelligently with Subordinate, Cross, and Non-Specific Subordinate,
References.

Sec.  4:  The replication data model:  replication of all sibling
entries rather than subtrees, or specific entries.

Sec.  5:  Improved DSA naming:  placing DSA names in a well known DSA
with root knowledge; placing DSA names in the higher (closer to the
root) portions of the DIT.

Sec.  6:  Definitions of objects necessary to represent knowledge
information in the DIT (rather than having DSAs maintain it as a ``local
matter'').

Sec.  7:  Definition of a simple replication protocol:  data propagation

                                  10






in a star-like fashion.

Sec.  8:  Definition of the ``Internet DSP'' Application Context to
allow for easier identification of Internet extensions.

Sec.  9:  Scaling limits and migration strategy.

Sec.  10:  Reserved for future definitions of application contexts,
object classes, and attributes necessary for replication

The result of the discussion was that Steve would revise the paper to
reflect replicated EDBs in pieces, rather than single units.  This
extension will be available in the next release.

In addition, Steve introduced the ASN.1 required to allow QUIPU to
transfers replicated EDBs in pieces, rather than single units.  This
extension will be available in the next release.

Steve also suggested that it would be appropriate to write a paper on
how to structure the DIT to achieve high performance and high
reliability using current replication methodologies.  He took this as an
action item for himself.  This document could then be put forward as a
statement of administrative guidelines on DSA naming, and DIT structure.

Issues raised:

Scaling:  the paper quotes 10000 units as the upper level of
scalability.  Steve noted that this refers to fan-out, not number of
entries, as the unit of replication is a single level, and not an entry
or subtree.  Steve also noted that QUIPU would be extended to allow
incremental updates of replicated data using an MHS. Since the master
DSA would always be reachable, there would be no problem in using MHS to
transfer EDBs while using replicated data to lookup the appropriate MHS
address.

DSA-DUA communities.  The paper as presented did not properly described
how a DSA decides whether or not a DUA and another DSA can communicate
directly.  Steve indicated that he would rephrase Section 2 to reflect
the fact that PSAP communities are used to make this decision, not
actual physical connections.

Vint asked whether access controls were replicated.  Steve answered that
private agreements must be used to maintain ACLs on replicated data, and
that an open environment would be publicly readable.  ACs are stripped
during replication as they are a private matter:  only published schema
get transferred.

                                  11






Paul questioned the Section 3 use of NSSRs:  the changing of NSSR
semantics from AND to OR would mean that multiple DSAs could not hold
different ``chunks'' of superior entries.  Steve indicated that he would
place a clear warning about this in the document.

Expiration dates on information:  Two separate issues were identified:
caching and replication.  It was determined that caching requires a TTL
mechanism, but that replication can use a simpler approach, such as
having a slave make regular ``pulls'' from the master.  Paul noted that
applications must be built to expect stale data (X.500 makes no
guarantees about data freshness), and that obtaining authoritative data
is an application problem.  It was decided that the unit of replication
would be delivered with an advisory refresh date.

Naming Architecture Registration

Steve:  In order to build useful applications, we need to extend the
Naming Architecture as supplied in the standard.  This paper describes
the formal administrative support for the creation of new elements in
the architecture.  The aim of this session is to discuss and define the
registration and maintenance methodologies (currently UCL maintains
pilot architecture for both the Internet and COSINE). UCL would maintain
ownership of this document until the end of the COSINE project in
December of 1992.  It is hoped that this work will have been
incorporated by the standards bodies by that time.  The document defines
an arbitration method for deciding what does and does not become part of
the naming architecture:  the editor has discretionary powers to
include, exclude, or modify, as needed, subject to appeals to the OSI-DS
Working Group mailing list, or arbitration from RARE and the OSI-DS
Working Group.

After a brief discussion, it was agreed that this document could be
issued (with minor revisions) as the first RFC of the DS series, and
that it would be updated every 3-6 months.

Issues raised:

Size of entries in a DIT: concern focused primarily on the size of the
photo attribute.  After some discussion, Steve indicated that he would
reword the document to indicate that participating DSAs can store
entries at their discretion, but that if they choose to store entries of
a given type, they must agree to store the published attribute maximum
sizes.

Several individuals mentioned concerns with certain object classes and
attribute types listed in the paper.  After gentle chiding from Steve,
they agreed to test the procedure by submitting complete ASN.1 proformas
for the additions they were concerned with.

                                  12






Steve indicated that he would make an arbitrary decision whether or not
to include the appendices Unix shells for Naming Architecture
Maintenance.  They were considered useful, but not for everyone.

Security Considerations

Peter Yee:  this paper identifies some of the security issues that must
be addressed when planning a security policy for the Internet pilot.

Steve Kille:  We must distinguish between X.500 as a user and as a
provider of security for the pilot.  As a provider, we can use X.509 in
a very straightforward fashion.

As a user of security services, we have a more interesting issue.
Unlike replication, we can work entirely within the standards.  We need
to prepare notes identifying the organizational issues involved, and
documenting methods addressing these issues.  There are three main areas
of concern:  authentication, access control, and remote updates.

After considerable discussion, it was agreed that Peter Yee should
revise and resubmit his document for consideration at the next meeting.
Steve Kille asked for volunteers to do the ``voluminous legwork''
required to research and resolve the open items in this area, but there
were no volunteers.

Issues raised:

Remote management.  There was considerable disagreement over the issue
of simple authentication as adequate security for remote management.
PEM representatatives and proponents of strong authentication felt that
simple authentication was not appropriate, as it would be too easy for
an outsider to remove or modify certificates, or keys.

One proposed solution that was partially acceptable is the requirement
that DSAs be able to store X.509 information (certificate lists, public
and private keys, certificates), and that DSAs using simple
authentication or no authentication would not allow remote updates.

Searchability.  Several participants indicated that without some form of
access control, they would not open their DSAs to the Internet, as they
did not want to allow ``DSA dumping''.  It was generally accepted that
authentication (simple or strong) or ``skinny pipes'' on searches would
be acceptable.

Steve Kille has since proposed a method of limiting searches and lists
to the OSI-DS Working Group mailing list.

                                  13






Applications that require X.509.  There was some debate over whether or
not the number of applications requiring strong authentication would
actually increase if it were provided.  More research is needed, as this
is a ``chicken or egg'' situation:  do the applications cry out for
X.509, or does X.509 invite new applications?

The relationship between the OSI-DS Working Group and RSADSI/PKP. It was
suggested that perhaps the IETF or the IAB could negotiate an
Internet-wide RSA license with the relevant bodies.  More liason work
and research is needed.

Next Meeting

SRI offered to host the next meeting in California, Feb.  12-13.  Steve
will issue a preliminary agenda in the near future.

AOB

Standard APIs.  It was agreed that the IETF should adopt a standard API
for the pilot.  X/OPEN and XDS were mentioned.  This item will be
discussed further at the next meeting.

The Canadian X.500/Library Project.  Dave Brent asked if the Working
Group should look into this.  Steve asked for volunteers to propose an
RFC on the subject.  This will be discussed at the next meeting.

Attendees

Karl Auerbach            [e-mail]
David Brent              [e-mail]
Ross Callon              [e-mail]
Lida Carrier             [e-mail]
Vinton Cerf              [e-mail]
Richard Colella          [e-mail]
Curtis Cox               [e-mail]
Tom Easterday            [e-mail]
Karen Frisa              [e-mail]
J. Joaquin Garcia-Luna   [e-mail]
Gita Gopal               [e-mail]
Martin Gross             [e-mail]
Ian Hamilton             [e-mail]
Alf Hansen               [e-mail]
Juha Heinanen            [e-mail]
Harold Jones             [e-mail]
Steve Kille              [e-mail]
Mark Knopper             [e-mail]
Paul Koski               [e-mail]

                                  14






Marilyn Martin           [e-mail]
Judy Messing             [e-mail]
Peter Mierswa            [e-mail]
Greg Minshall            [e-mail]
Paul Mockapetris         [e-mail]
Daniel Molinelli         [e-mail]
James Mostek             [e-mail]
David Oran               [e-mail]
Marshall Rose            [e-mail]
Theresa Senn             [e-mail]
Harvey Shapiro           [e-mail]
Karen Sollins            [e-mail]
You-Bong Weon-Yoon       [e-mail]
Peter Whittaker          [e-mail]
Linda Winkler            [e-mail]
Dan Wintringham          [e-mail]
Russ Wright              [e-mail]
Sze-Ying Wuu             [e-mail]
Peter Yee                [e-mail]
David Zimmerman          [e-mail]



                                  15